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REMARKS 

This is a full and timely response to the outstanding non-final Office Action mailed 
November 20, 2006 (Paper No. 20061114). Upon entry of this response, claims 3-5, 7-11, 16, 
18, 62-64, 66-77, 79, and 82-1 12 are pending in the application. Applicant respectfully requests 
that there be reconsideration of all pending claims. 

I. Rejection of Claims 3-11. 16. 18. 62-64. 66-77. 79. and 82-1 12 under 35 U.S.C. § 1 12. 
Second Paragraph 

Claims 3-11, 16, 18, 62-64, 66-77, 79, and 82-112 have been rejected under 35 U.S.C. 
§1 12, second paragraph, as alleged being indefinite for failing to particularly point out and 
distinctly claim the subject matter which Applicant regards as his invention. Specifically, the 
Office Action (p. 2, section 4) indicates that the claims are indefinite becausethe first, second 
and third channel are not defined in the specification. Applicant respectfully traverses this 
rejection and requests that the rejection be withdrawn. 

Applicant first notes that "there is no requirement that the words in the claim must match 
those used in the specification disclosure." MPEP 2173.05(f). Applicant respectfully submits that 
each claim, when read as a whole, does describe the recited channels in a definite manner. 

Claim 1 clearly defines the first channel as connecting the first communication device 
and the troubleshooting portal device which implements the claimed method: "receiving a 
specification from the first communication device over a first communication channel". The 
Examiner's attention is respectfully directed to reference numbers 156 in FIG. 3 and 208 in 
FIG. 4. 

In addition, claim 1 clearly defines the second channel as one used to configure a route 
between the first communication device and the second communication device: "configuring a 
network device to establish a route between the first communication device and the second 
communication device using the identified statically configured second communication channel". 
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The Examiner's attention is respectfully directed to reference numbers 152 in FIG. 3 and 218 in 
FIG. 4. 

Finally, claim 112 clearly defines the third channel as one connecting two other 
channels: "instructing a network device to couple the statically configured predefined channel to 
the second channel, producing a third channel". The Examiner's attention is respectfully 
directed to p. 21, lines 10-12 of the instant specification 

II. Rejection of Claims 3-1 1. 16. 18. 62-64. 66-77. and 87-111 under 35 U.S.C. §102 

Claims 3-11,16,18, 62-64, 66-77, and 87-1 1 1 have been rejected under §1 02(e) as 

allegedly anticipated by Rekhter et al. (U.S. 6,339,595). Applicant respectfully traverses this 

rejection. First, this rejection fails to address all claimed features and limitations, and therefore is 

deficient. The MPEP states "where a claim is rejected for any reason relating to the merits 

thereof if should be rejected' and the ground of rejection fully and clearly stated". MPEP § 

707.07(d). The Office Action has failed to provide any guidance as to where many of the 

claimed features are allegedly disclosed in Rekhter et al., making it extremely difficult for 

Applicant to accurately and fairly respond. Accordingly, Applicant respectfully submits that the 

next Office Action must be made non-final: since no amendments are made herein, a more 

completely stated rejection would necessarily constitute "new grounds". 

However, in an effort to advance prosecution of this application, additional arguments 

are set forth below as to why Rekhter et al. fails to teach, disclose, or suggest most of the 

features recited in independent claims 63, 87, and 105. For at least these reasons, the rejection 

should be withdrawn. A proper rejection of a claim under 35 U.S.C. §102 requires that a single 

prior art reference disclose each element of the claim. See, e.g., W.L. Gore & Assoc., Inc. v. 

Garlock, Inc., 721 F.2d 1540, 220 U.S.P.Q. 303, 313 (Fed. Cir. 1983). 
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A. Claims 63 and 85 

1. Rekhter et al. does not teach "receiving a specification from the first communication 
device. . .the specification comprising at least one predefined identifier of the second 
communication device" 

In rejecting this feature of claims 63 and 85, the Office Action (p. 3, para. 3) points to 
several different features in Rekhter et al.\ an IP address; an edge router; a router's Forward 
Information Base table (FIB);and a router's Tag Information Base table (TIB). The Office Action 
clearly alleges that the identifier recited in claims 63 and 85 ("specification comprising at least 
one predefined identifier") corresponds to an IP address. However, it is not at all clear from the 
rejection which element of Rekhter et al. allegedly corresponds to the specification which 
includes the identifier. Nor is it clear which element allegedly corresponds to the "first 
communication device" - from which the specification is received - or which element allegedly 
correspond to the "second communication device" - which is identified by the specification. 

As known to a person of ordinary skill in the art, a router receives packets which are to 
be routed, and also receives information from other routers. Therefore, Applicant will assume, 
arguendo, that the Office Action is actually alleging that the "specification" recited in claims 63 
and 85 corresponds either a) a packet to be forwarded or b) information received from another 
router. However, Applicant submits that neither of these corresponds to a "specification" 
received from a first device and comprising an identifier of a second device, as recited in claims 
63 and 85. 

2. Rekhter et al. does not teach "receiving, from the first communication device, a 
request to establish connectivity between the first and the second communication 
device" 

The Office Action (p. 3, para. 4) alleges that this feature is taught by PE1 and PE2 in 
FIG. 1 of Rekhter et al. Although not clearly stated in the rejection, Applicant will first assume, 
arguendo, PE1 and PE2 correspond to the first and second devices recited in claims 63 and 85. 
However, there is nothing in FIG. 1 that corresponds to the "request to establish connectivity". 
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3. Rekhter et al. does not teach "wherein the second communication device is located 
in a second network operated by a second provider different than the first provider" 

The Office Action (p. 3, para. 4) alleges that this feature is taught by PE1 and PE2 in 
FIG. 1 of Rekhter et al. However, Rekhter et al. clearly states that PE1 and PE2 are in the same 
network - the service provider's network. (See Col. 2, lines 55-67.) In contrast, claims 63 and 85 
recite that "the second communication device is located in a second network operated by a 
second provider different than the first provider". 

4. Rekhter et al. does not teach "identifying a statically configured second 
communication channel to the second communication device that is associated with 
the predefined identifier" 

The Office Action (p. 4, para. 1) alleges that this feature is taught by Rekhter et al. at 
Col. 30, lines 30-40. Applicant disagrees. This passage in Rekhter et al. merely describes a 
precondition for proper operation of the router described in Rekhter et al: "Configuration of the 
CE Routers... If the CE router is at a stub site then. ..if it uses a different PE router for inter-VPN 
traffic than for intra-VPN traffic, then it must be configured with appropriate static routes, and 
must inject them into its IGP." This passage teaches, at most, that routes are statically 
configured. It does not disclose "identifying" static routes, as recited in claims 63 and 85. 
Furthermore, the channel recited in claims 63 and 85 has several specific features: "second 
communication channel to the second communication device that is associated with the 
predefined identifier. A vague teaching of "appropriate static routes" is not equivalent to these 
claimed features. 

5. Rekhter et al. does not teach "configuring a network device to establish a 
route. . .using the identified statically configured second communication channel" 

The Office Action (p. 4, para. 2) alleges that this feature is taught by Rekhter et al. at 
Col. 30, lines 30-40. Applicant disagrees. As noted above, this passage in Rekhter et al. merely 
states that a configuration including static routes is a precondition for proper operation of the 
router. However, claims 63 and 85 do not recite configuring a static route. Instead, claims 63 
and 85 recite establishing a route "using the identified statically configured second 
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communication channef, which is not taught by the cited passage in Rekhteret al. 

Furthermore, Rekhteret al. does not teach that a computer performs static route configuration, 

and Applicant submits that a person of ordinary skill in the art would understand it to be 

performed by a human network administrator. In contrast, claims 63 and 85 recite "configuring" 

as a step of a computer-implemented method. 

6. Rekhter et al. does not teach "receiving at least troubleshooting data and a test from 
the first communication device" 

The Office Action (p. 4, para. 3) alleges that this feature is taught by Rekhteret al. at 
Col. 4, lines 25-33 and Col. 42, lines 10-18. Applicant disagrees. Although the words 
"troubleshooting" and "test" do appear in Rekhteret al., these passages in Rekhter et al. have 
nothing to do with the features recited in claims 63 and 85. 

The first cited passage in Rekhter et al. simply states: "If the routing algorithm fails, two 
different administrations must work together to troubleshoot it." This is not equivalent to 
"receiving.... troubleshooting data", nor is this troubleshooting described as being performed by 
a computer, as recited in claims 63 and 85. The second cited passage in Rekhter et al. is also 
irrelevant to the claim, simply stating: "In order to establish communications over a point-to-point 
link, each end of the PPP link must first send LCP packets to configure and test the data link." 
This passage teaches, at most, that receiving data can be used to test the link. It does not teach 
"receiving... .a test" as recited in claims 63 and 85. 

B. Claim 87 

1. Rekhter et al. does not teach "receiving a specification from the first communication 
device. . .the specification comprising at least one predefined identifier of the second 
communication device" 

In rejecting this feature of claim 87, the Office Action (p. 9, para. 4) points to several 
different features in Rekhter et al: an IP address; an edge router; a router's Forward Information 
Base table (FIB);and a router's Tag Information Base table (TIB). The Office Action clearly 
alleges that the identifier recited in claim 87 ("specification comprising at least one predefined 
identifier") corresponds to an IP address. However, it is not at all clear from the rejection which 
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element of Rekhteret al. allegedly corresponds to the specification which includes the identifier. 
Nor is it clear which element allegedly corresponds to the "first communication device" - from 
which the specification is received - or which element allegedly corresponds to the "second 
communication device" - which is identified by the specification. 

As known to a person of ordinary skill in the art, a router receives packets which are to 
be routed, and also receives information from other routers. Therefore, Applicant will assume, 
arguendo, that the Office Action is actually alleging that the "specification" recited in claim 87 
corresponds either a) a packet to be forwarded or b) information received from another router. 
However, Applicant submits that neither of these corresponds to a "specification" that is 
received from a first device and that comprises an identifier of a second device, as recited in 
claim 87. 

2. Rekhter et al. does not teach "receiving, from the first communication device, a 
request to establish connectivity between the first and the second communication 
devicer" 

The Office Action (p. 9, para. 5) alleges that this feature corresponds to a "request to 
establish PE1" at Col. 16, lines 12-27 of Rekhter et al. Applicant disagrees. This portion of 
Rekhter et al. appears to disclose a provider edge router (PE1) requesting that a neighboring 
provider transit router (P1) use a particular tag. The requesting router PE1 makes this request 
by sending a TDP Bind message to neighboring router P1 . Such a request between routers is 
not a portal receiving a request from a first device to establish connectivity between the first 
device and a second device, as recited in claim 87. 

3. Rekhter et al. does not teach "the second communication device located in a second 
network operated by a second provider different than the first provider" 

The Office Action (p. 9, para. 5) alleges that this feature corresponds to a "request to 
establish PE1" at Col. 16, lines 12-27 of Rekhter et al. Rekhter etal. clearly states that PE1 and 
P1 are in the same network - the service provider's network. (See Col. 2, lines 55-67.) In 
contrast, claim 87 recites that the second communication device is "located in a second network 
operated by a second provider different than the first provider". 
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4. Rekhter et al. does not teach "identifying a predefined second communication 
channel to the second communication device that is associated with the predefined 
identifier" 

The Office Action (p. 10, para. 1) alleges that this feature is taught by CE, CE1 and PE1 
in FIG. 1 of Rekhter et al. Since the rejection mentions three elements (CE, CE1 , and PE1 ), it is 
not at all clear from the rejection which one allegedly corresponds to the "second 
communication device". Furthermore, there is nothing in FIG. 1 that corresponds to the step 
"identifying". 

5. Rekhter et al. does not teach "instructing a network device to couple the first 
communication channel to the second communication channel. . .using the predefined 
second communication channel" 

In rejecting this feature of claim 87, the Office Action (p. 10, para. 2) points to several 
different features in Rekhter et al.: an edge router; a router's Forward Information Base table 
(FIB); a router's Tag Information Base table (TIB); and static route configuration. It is not at all 
clear from the rejection which of these elements allegedly corresponds to the "first 
communication channel" or the "second communication channel". Applicant submits that none 
of these elements in Rekhter et al. corresponds to the channels recited in claim 87, and that 
none of these elements corresponds to the step of "instructing" recited in claim 87. 

6. Rekhter et al. does not teach "receiving at least troubleshooting data and a test from 
the first communication device" 

The Office Action (p. 10, para. 3) alleges that this feature is taught by Rekhter et al. at 
Col. 4, lines 25-33 and Col. 42, lines 10-18. Applicant disagrees. Although the words 
"troubleshooting" and "test" do appear in Rekhter et al., these passages in Rekhter et al. have 
nothing to do with the features recited in claim 87. 

The first cited passage in Rekhter et al. simply states: "If the routing algorithm fails, two 
different administrations must work together to troubleshoot it." This does not describe 
"receiving. ...troubleshooting data", nor is this troubleshooting procedure described as being 
performed by a computer, as recited in claim 87. The second cited passage in Rekhter et al. is 
also irrelevant to the claim, simply stating: "In order to establish communications over a point-to- 
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point link, each end of the PPP link must first send LCP packets to configure and test the data 
link." This passage teaches, at most, that receiving data can be used to test the link. It does not 
teach "receiving.... a test" as recited in claim 87. 

C. Claims 3-11.16.1 8. 62. 64. 66-77. 88-1 04. and 1 06-1 1 1 

Since claims 63, 87, and 1 05 are allowable, Applicant submits that claims 3-11, 16, 18, 

62, 64, 66-77, 88-104, and 106-1 1 1 are allowable for at least the reason that each depends 

from an allowable claim. In re Fine, 837 F.2d 1071, 5 U.S.P.Q. 2d 1596, 1598 (Fed. Cir. 1988). 

Therefore, Applicant requests that the rejection of claims 3-11, 16, 18, 62, 64, 66-77, 88-104, 

and 106-111 be withdrawn. 

III. Rejection of Claims 79. 82-86. and 1 12 under 35 U.S.C. §103 

Claims 79, 82-86, and 1 12 have been rejected under §103(a) as allegedly obvious over 

Rekhter et al. (6,339,595) in view of Burke et al. (6,996,067). Applicant respectfully traverses 

this rejection. First, this rejection fails to address all claimed features and limitations, and 

therefore is deficient. The rejection of independent claim 1 12 is substantially the same as the 

rejection of independent claims 63, 87, and 105, even though independent claim 1 12 contains 

different features. For example, the rejection of claim 1 12 fails to address "a troubleshooting 

manager device" and "a managed communication device". 

Next, the MPEP states "where a claim is rejected for any reason relating to the merits 
thereof if should be 'rejected' and the ground of rejection fully and clearly stated". MPEP § 
707.07(d). The Office Action has failed to provide any guidance as to where many of the 
claimed features are allegedly disclosed in Rekhter et al. and Burke et al., making it extremely 
difficult for Applicant to accurately and fairly respond. Accordingly, Applicant submits that the 
next Office Action must be made non-final: since no amendments are made herein, a more 
completely stated rejection would necessarily constitute "new grounds". 

However, in an effort to advance prosecution of this application, additional arguments 
are set forth below as to why the proposed combination of Rekhter et al. and Burke et al. fails 
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to teach, disclose, or suggest most of the features recited in independent claim 1 12. For at least 
these reasons, the rejection should be withdrawn. It is well established at law that, for a proper 
rejection of a claim under 35 U.S.C. §103 as being obvious based upon a combination of 
references, the cited combination of references must disclose, teach, or suggest, either 
implicitly, all elements/features/steps of the claim at issue. See, e.g., In re Dow Chemical, 5 
U.S.P.Q.2d 1529, 1531 (Fed. Cir. 1988); In re Keller, 208 U.S.P.Q.2d 871, 881 (C.C.P.A. 1981). 

A. Claim 112 

1. The combination does not teach "creating, upon user request, a statically configured 
predefined first channel between the managed communication device and an access 
unit within an access provider network" 

The Office Action (p. 1 3, para. 1 ) alleges that this feature is taught by Rekhter et al. at 
Col. 30, lines 30-40 and Col. 18, lines 39-57. Applicant disagrees. The first cited passage in 
Rekhter et al. merely describes static route configuration as a precondition for proper operation 
of the router described in Rekhter et al. Applicant will first assume, arguendo, that the static 
route in Rekhter et al. corresponds to a "statically configured predefined first channel" as recited 
in claim 1 12. Even so, Rekhter et al. does not describe the static route in detail, saying on that 
"appropriate static routes" are created. In contrast, the channel recited in claim 112 is 
specifically described as "between the managed communication device and an access unit 
within an access provider network", a feature not disclosed in Rekhter et al. 

Furthermore, Rekhter et al. does not teach that a computer performs static route 
configuration, and Applicant submitsthat a person of ordinary skill in the art would understand it 
to be performed by a human network administrator. Nor does Rekhter et al. teach that the static 
route is created upon user request. In contrast, claim 1 12 recites "creating. ..a statically 
preconfigured predefined first channel" as a step of a computer-implemented method, and this 
step is performed "upon user request". 

The addition of Burke etal. does not cure these deficiencies of Rekhter et al.. Nor does 
the Office Action allege that Burke et al. discloses these features. 



21 



Serial No.: 09/650,867 
Docket No.: 061607-1390 

2. The combination does not teach "receiving, over a second channel, an identifier of 
the managed communication device from the troubleshooting manager device" 

The Office Action (p. 13, para. 2) alleges that this feature corresponds to an IP address 
as described in Col. 7, lines 23-49 of Rekhter et al. Applicant disagree. Applicant admits that an 
IP address can be used as a device identifier. Even so, there is no description in Rekhter et al. 
of an IP address being used to identify a "managed communication device", and there is no 
discussion in Rekhter et al. of such an identifier being received from a "troubleshooting manager 
device" as recited in claim 112. 

The addition of Burke etal. does not cure these deficiencies of Rekhter et al.. Nor does 
the Office Action allege that Burke et al. discloses these features. 

3. The combination does not teach "receiving, from the troubleshooting manager 
device, a request to establish connectivity between the troubleshooting manager 
device and the identified managed communication device" 

The Office Action (p. 13, para. 3) alleges that this feature corresponds to a "request to 
establish PE1" at Col. 16, lines 12-27 of Rekhter et al. Applicant disagrees. This portion of 
Rekhter et al. appears to disclose a provider edge router (PE1) requesting that a neighboring 
provider transit router (P1) use a particular tag. The requesting router PE1 makes this request 
by sending a TDP Bind message to neighboring router P1 . A TDP Bind message between 
routers is not an "identifier of the managed communication device" as recited in claim 112. Nor 
does Rekhter et al. describe any of the routers involved as a "managed communication device" 
or a "troubleshooting manager device" as recited in claim 1 12. 

The addition of Burke etal. does not cure these deficiencies of Rekhter et al.. Nor does 
the Office Action allege that Burke et al. discloses these features. 

4. The combination does not teach "instructing a network device to couple the statically 
configured predefined channel to the second channel, producing a third channel"" 

The Office Action (p. 13, para. 4) alleges that this feature is taught by "PE1 connected to 
CE, CE1 and P1" in FIG. 1 of Rekhter et al. Since the rejection mentions four routers, it is not at 
all clear from the rejection which one allegedly corresponds to "a network device" as recited in 
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claim 112, or which connections between routers allegedly correspond to "the configured 

predefined channel", "the second channel" and "a third channel". Furthermore, there is nothing 

in FIG. 1 that corresponds to the step "instructing". 

The addition of Burke etal. does not cure these deficiencies of Rekhter et al.. Nor does 

the Office Action allege that Burke et al. discloses these features. 

5. The combination does not teach "receiving at least troubleshooting data and a test 
from the first communication device" 

The Office Action (p. 13, para. 5) alleges that this feature is taught by Rekhter et al. at 
Col. 4, lines 25-33 and Col. 42, lines 10-18. Applicant disagrees. Although the words 
"troubleshooting" and "test" do appear in Rekhter et al., these passages in Rekhter et al. have 
nothing to do with the features recited in claim 112. 

The first cited passage in Rekhter et al. simply states: "If the routing algorithm fails, two 
different administrations must work together to troubleshoot it." This does not describe 
"receiving. ...troubleshooting data", nor is this troubleshooting procedure described as being 
performed by a computer, as recited in claim 1 12. The second cited passage in Rekhter et al. is 
also irrelevant to the claim, simply stating: "In order to establish communications over a point-to- 
point link, each end of the PPP link must first send LCP packets to configure and test the data 
link." This passage teaches, at most, receiving data, where the receipt of data can be used to 
test the link. It does not teach "receiving.... a test" as recited in claim 1 12. 

The addition of Burke etal. does not cure these deficiencies of Rekhter et al.. Nor does 
the Office Action allege that Burke et al. discloses these features. 
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B. Claims 79 and 82-86 

Since independent claim 1 12 is allowable, Applicant submits that claims 79 and 82-86 

are allowable for at least the reason that each depends from an allowable claim. In re Fine, 

837 F.2d 1071, 5 U.S.P.Q. 2d 1596, 1598 (Fed. Cir. 1988). Therefore, Applicant requests that 

the rejection of claims 79 and 82-86 be withdrawn. 
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CONCLUSION 

Applicant respectfully requests that all outstanding objections and rejections be 
withdrawn and that this application and presently pending claims 3-5, 7-11, 16, 18, 62-64, 
66-77, and 82-1 12 be allowed to issue. Any statements in the Office Action that are not explicitly 
addressed herein are not intended to be admitted. In addition, any and all findings of inherency 
are traversed as not having been shown to be necessarily present. Furthermore, any and all 
findings of well-known art and official notice, or statements interpreted similarly, should not be 
considered well known since the Office Action does not include specific factual findings 
predicated on sound technical and scientific reasoning to support such conclusions. If the 
Examiner has any questions or comments regarding Applicant's response, the Examiner is 
encouraged to telephone Applicant's undersigned counsel. 

By: /Karen G. Hazzah/ 

Karen G. Hazzah, 
Reg. No. 48,472 

Thomas, Kayden, Horstemeyer 

& RlSLEY, L.L.P. 

100 Galleria Parkway, NW 
Suite 1750 

Atlanta, Georgia 30339-5948 
Tel: (770)933-9500 
Fax: (770)951-0933 
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